This document shows the most common assertions you might encounter. Each entry in this document lists the library, file, method, and a short explanation of the assertion.
Can't register a class as archivable if it doesn't have RTTI
Library: ODFFoundation
File: FWArDyna.cpp
Method: FW_CPrivArchiver::AddNameToLabelPair
Explanation: This error should never happen if you're using native RTTI. If you're using ODF RTTI, then you've forgotten to use the FW_DECLARE_CLASS and FW_DEFINE_CLASS_Mx macros for a class that is being registered as archivable. If you get this error you'll need to figure out which class is being registered for archiving. Since the RTTI isn't available it's not possible to get a class name string, but the four character class label is available. You'll need to get that information using a debugger.
If an initialize function is registered, a destroy function must be too.
Library: ODFFoundation
File: FWArDyna.cpp
Method: FW_SPrivArcFun::FW_SPrivArcFun
Explanation: Archivable classes can use one-step or two-step initialization. Classes that use one-step initialization use just the "create" function, and do not use an "initialize" function (a NULL pointer is passed to the FW_REGISTER_ARCHIVABLE_CLASS macro). If an initialize function is specified, the class is using two-step initialization. Two-step initialization is a potential source of a resource-leak if an exception is thrown by the initialization function. To prevent this leak, it is necessary to provide a destroy function to destroy the object created by the "create" function. You'll get this assertion if you've specified a non-NULL value for the initialize function but specified NULL for the destroy function.
Object registry ID was not found in registry
Library: ODFFoundation
File: FWArDyna.cpp
Method: FW_CPrivArchiver::PrivCreateObject
Explanation: If the above assertion fails, the most likely explanation is that some data read from the stream is not in sync with some data written to the stream. Another potential problem is that the stream contains a reference to an object that was supposed to be preregistered at runtime, but for some reason wasn't. This can be checked by using a debugger. Was the object ID returned by the object registry a negative value? Finally, a last possibility is that the stream of data has been corrupted in some other way.
<Class Label ID> class not registered for archiving. Forgot FW_DO_NOT_DEAD_STRIP ?
Library: ODFFoundation
File: FWArDyna.cpp
Method: ClassLabel_Create
Explanation: A class label ID was encountered in a stream for which no class has been registered. Either you forgot the FW_REGISTER_ARCHIVABLE_CLASS macro, or the translation unit containing it wasn't linked into your part editor. This might happen due to dead-stripping by the linker. You can prevent dead-stripping of archivable classes using the FW_DO_NOT_DEAD_STRIP macro. Call the macro for the archivable class from some function that you know will not be dead-stripped. One such place is your part's Initialize method.
In particular if you create views from resources remember to use FW_DO_NOT_DEAD_STRIP for all the view classes which are not referenced in your code. You can call it in your frame's PostCreateViewFromStream method as ODF samples do.
Note: in the current version you may see an assertion message containing garbled characters between the 4 characters class label and the string "class not registered for archiving...", just ignore these characters.
The following table lists the class labels and corresponding view and menu classes defined by ODF:
Label Class
bscl FW_CPrivBaseScroller
butn FW_CButton
edvw FW_CEditView
gpbx FW_CGroupBox
grbx FW_CGrowBox
lbox FW_CListBox
mnit FW_CMenuItem
picv FW_CPictSView
popm FW_CPopupMenu
pdmn FW_CPullDownMenu
rcls FW_CRadioCluster
sbsc FW_CScrollBarScroller
scbr FW_CScrollBar
sclr FW_CScroller
seit FW_CSeparatorItem
stxt FW_CStaticText
suit FW_CSubMenuItem
tgit FW_CToggleItem
txit FW_CTextItem
No registered archiving functions for class label
Library: ODFFoundation
File: FWArDyna.cpp
Method: FW_CPrivArchiver::PrivCreateObject
Explanation: Under normal circumstances this assertion could only happen if the "<Class Label ID>' class not registered for archiving. Forgot FW_DO_NOT_DEAD_STRIP ?" assertion had already been triggered. If you see this assertion and did not see the "Forgot FW_DO_NOT_DEAD_STRIP?" assertion, please report a bug to the ODF team. See above for more information about this problem.
Attempt to create object from stream with NULL create function
Library: ODFFoundation
File: FWArDyna.cpp
Method: FW_CPrivArchiver::PrivCreateObject
Explanation: The archiving subsystem allows you to pass a NULL pointer in the place of the "create" function parameter. However, if the archiver encounters a class label ID for such a class while reading from a stream then it will be unable to create the object.
Class <className> has already been registered as archivable!
Library: ODFFoundation
File: FWArDyna.cpp
Method: FW_CPrivArchiver::AddNameToLabelPair
Explanation: You probably used the FW_REGISTER_ARCHIVABLE_CLASS macro twice for the same class. If you want to register previous versions of the class, use the FW_REGISTER_PREV_VERSION_ARCHIVABLE_CLASS macro.
Exception error, calling terminate()
Library: ODFFoundation
File: FWExcImp.cpp
Method: DoTerminate
Explanation: This message appears only if a problem occurs and you're using ODF exceptions, but the problem can happen with either native or ODF exceptions. One way the problem can occur is to throw an exception inside a scope for which there is no active try block. This might happen if you've created a SOM class and you implement one or more methods without a try block (ODF uses try blocks for all of its SOM entry points).
Why is an autodestruct object of class <classname> being constructed in a bad context? See FWExcImp.cpp for possible causes.
Library: ODFFoundation
File: FWExcImp.cpp
Method: FW_AutoConstructed
Explanation: Possible causes:
1) The autodestruct object is a member of another object, which itself is not an autodestruct object. This other object is being allocated via new, not FW_NEW. If so, this is a programmer error. Make the other object's class be autodestruct, and use FW_NEW.
2) This is a static object of a shared library that has just been loaded, and static constructors are being executed. We have attempted to detect this condition and not report it as an error, but may not have eliminated it for all environments. If this is the case, it is not a programming error. You can safely continue execution. Note: if you move this code into an application (as opposed to a shared library), you may need to set FW_gInStaticInit to zero in your main() to inform this subsystem that static initialization is complete.
3) A case similar to 2) is possible. If a static autodestruct object is declared in a function, the compiler is not obligated to initialize it at static initialization time. It can (and should) wait until the function is first called. This case is very difficult to detect (without help from the compiler!). It is not a programming error, and it is safe to continue excecution.
4) You are using threads and did not call FW_Thread_NoteSwitch when threads were switched.
The autodestruct class <classname> is missing an FW_END_CONSTRUCTOR.
Library: ODFFoundation
File: FWExcImp.cpp
Method: FW_AutoDestructed
Explanation: An FW_START_DESTRUCTOR is executing for a class that was constructed without an FW_END_CONSTRUCTOR. Look at every constructor of the class <classname> and make sure it has an FW_END_CONSTRUCTOR. Don't forget that the compiler might generate a copy constructor for you if you haven't declared one. If you declare a class to be autodestruct, the compiler generated copy constructor will not work; you must provide your own definition for the copy constructor. Note that a compiler will also generate a default constructor, but only if you haven't declared any constructors.
An autodestruct class is missing an FW_END_CONSTRUCTOR or FW_START_DESTRUCTOR. Likely candidates: <class1> and <class2> respectively.
Library: ODFFoundation
File: FWExcImp.cpp
Method: FW_AutoDestructed
Explanation: This is similar to the message above, but it is a slightly different case, and harder to pinpoint at runtime. The error is probably a missing FW_START_DESTRUCTOR in class2's destructor, but it may be a missing FW_END_CONSTRUCTOR in one of class1's constructors.
The autodestruct class <classname> is missing an FW_START_DESTRUCTOR
Library: ODFFoundation
File: FWExcImp.cpp
Method: FW_PrivTryBlockContext_Destroy
Explanation: A try block is going out of scope, but an autodestruct object of class <classname> in the try block's scope didn't clean up after itself by calling FW_START_DESTRUCTOR in its destructor. Find the destructor of the class (classname::~classname) and add the FW_START_DESTRUCTOR macro as the first line of the destructor.
FW_CFixedAllocator: An object of type <classname> has not been deleted properly.
Library: ODFOS
File: FWFixMem.cpp
Method: FW_CFixedAllocator::~FW_CFixedAllocator
Explanation: FW_CInkRep, FW_CStyleRep, FW_CFontRep, and FW_CPatternRep are allocated using a pool allocation scheme. This assertion indicates that one of these objects was not disposed when the allocator for the objects was disposed, indicating a possible memory leak. This situation can arise if you allocate a FW_CInk, FW_CStyle, FW_CFont or FW_CPattern object on the heap, instead of on the stack, and forgot to delete it. You may also have one of these objects as a field of another object that you are not disposing correctly.
Environment has non-OpenDoc error
Library: ODFOS
File: FWODExce.cpp
Method: FW_GetEvError
Explanation: Don't know what to do, the “Environment” variable contains a non-OpenDoc error.
FW_CMenuItem::Read should never have been called
Library: ODFOS
File: FWAMnuIt.cpp
Method: FW_CMenuItem::Read
Explanation: ODF is trying to instantiate a FW_CMenuItem, which is an abstract base class. This could be the result of an error in your menu resource. In particular you may have left an extra comma after the last menu item (ODFRC doesn't catch this error at compile time).
Trying to set the Facet Part Info of a non-display facet
Library: ODFOS
File: FWFctInf.cpp
Method: FW_SetFacetRefCon
Explanation: FW_SetFacetRefCon was called with a facet parameter that was not a display facet. ODF uses the facet's PartInfo field to store information about the device. A part is not allowed to set the PartInfo field of a non-display facet.
Failed to load menu resource
Library: ODFOS
File: FWMnuBar.cpp
Method: FW_CMenuBar::InitializeFromResource
Explanation: We use a try-catch block purely to warn about a common mistake. If you forget to add the resource containing your menus to your project, or specify the wrong menu resource ID, the code will throw an exception that probably won't get caught until the SOM entry point from OpenDoc. OpenDoc will display an error dialog that isn't particularly helpful in diagnosing the problem.
Your view or frame is not a FW_MReceiver, or you forgot RTTI macros
Library: ODFFramework
File: FWControl.cpp
Method: FW_CControl::InitializeFromStream
Explanation: If you get this error:
1) Make sure that you are linking this control to a view or frame that inherits from FW_MReceiver.
2) Make sure that you use the RTTI macro FW_DEFINE_CLASS_Mx, as in the following example:
in FW_MEventHandler::PrivInsert, handler already inserted
Library: ODFFramework
File: FWEventH.cpp
Method: FW_MEventHandler::PrivInsert
Explanation: FW_MEventHandler::AdoptEventHandler() was called twice with the same event handler. An event handler cannot adopt another event handler more than once.
Can't call SetLocation on a FW_CFrame
Library: ODFFramework
File: FWFrame.cpp
Method: FW_CFrame::SetLocation
Explanation: You cannot call SetLocation on a view of type FW_CFrame because it is the root view of your frame (i.e. its location is always 0, 0).
The part info resource is missing
Library: ODFFramework
File: FWPart.cpp
Method: FW_CPart::Initialize
Explanation: All ODF parts must have a Part Info resource. You either forgot to include the resource in your project or passed the wrong ID to the FW_CPart constructor.
Cannot use a ScrollBarScroller here, create a separate content view
Library: ODFFramework
File: FWScrolr.cpp
Method: FW_CScrollBarScroller::PrivCheckFrame
Explanation: ODF doesn't allow a frame to use a scroller with scroll bars if the frame does not have a content view. Without the content view, the scroll bars will end up moving with the rest of the frame's content! A frame that is its own content view can only use a basic FW_CScroller object. The frame's content can be scrolled with mechanisms such as hand-scrolling or auto-scrolling.
Failed to load view resource.
Library: ODFFramework
File: FWSView.cpp
Method: FW_CSuperView::CreateSubViewsFromResource
Explanation: We use this try-catch block purely to warn about a common mistake. If you forget to add the resource containing your views to your project, or specify the wrong view ID, the above code will throw an exception that probably won't get caught until the SOM entry point from OpenDoc. OpenDoc will display an error dialog that isn't particularly helpful in diagnosing the problem.
preferredKind != NULL
Library: ODFFramework
File: FWPart.cpp
Method: FW_CPart::PrivDeterminePreferredKind
Explanation: You may get this error when opening stationery. It means that you created the stationery before installing the ODFLibrary. You need to install the ODF Library, and recreate stationery before proceeding.
